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(54) Computer system with evolving printer 

(57) A computer system (100) includes a computer 
(110, 126) and a peripheral (112, 124. 134. 144) the 
peripheral having an object oriented run-time environ- 
ment (e.g., JAVA) and object resource brokering facili- 
ties (e.g.. CORBA). Putrfic methods of the peripheral 
(242, 246, 248) are exposed to objects of the computer 
system and vice versa for more efficient p^ipheral 
operation and shared program code. 
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Description 

FIELD OF THE INVENTION 

[0001] Tills invention relates to printers and to meth- s 
ods of expanding printer capabilities In response to 
evolving printer and computer system requirements. 

BACKGROUND OF THE INVENTION 

10 

[0002] Conputer systems including those used by 
office workers, technidans. and scientists are subject to 
frequent change. Some change Is attributable to 
improvements that make tiie computer system perform 
more closely to goals of a predetermined computer sys- is 
tem specification. Other change is attributable to 
improvements beyond tiie scope of the original specifi- 
cation, for example when users' expectations change as 
to what the computer system ought to be able to do. 
Rapid application of new technologies has caused 20 
users to consider components obsolete when desirable 
functions, which were not part of the original compo- 
nent, cannot be added. 

[0003] The conventional computer system includes a 
general purpose computer component having memory 2S 
and processing resources tightiy coupled witiiin one 
enclosure. Other components, as for example input/out- 
put equipment, are conventionally packaged in other 
separate enclosures. These separately enclosed com- 
puter system components, known as "peripherals," 30 
have grown in complexity so that some, including laser 
printers, for example, include a special purpose connput- 
ing circuit with considerable internal memory and 
processing resources dedicated to the execution of a 
special purpose operating system and a peripheral pro- 35 
gram. 

[0004] General purpose computing components 
(computers) and input/output equipment (printers, scan- 
ners, etc.) are developed and marketed by independent 
suppliers. Functional cooperation of a computer and 40 
peripheral conventionally relies on driver software, run- 
ning on the computer, to operate tiie peripheral in an 
efficient manner. Poor quality operation may result 
when driver software is unable to take advantage of 
peripheral functions embedded in the peripheral pro- 45 
gram. As a case in point, poor printing quality may result 
when driver software is unable to pass geometric 
graphic image Items such as circles to the printer, 
renders graphic image items into bit-map form, and 
passes only bit-map data to tiie printer. No advantage is 50 
taken of edge enhancement functions of the peripheral 
program in such a case. 

[0005] The peripheral program code is conventionally 
stored in nonvolatile memory in directiy executable for- 
mat. The peripheral program's capabilities are evi- ss 
denced as functional aspects (functions) of the 
peripheral. To modify or add functions, nonvolatile mem- 
ory conponents are added or installed in place of origi- 



nal memory components. These added components 
provide additional stored, directiy executable, program 
code. Some functions, such as tiie ability of a laser 
printer to print in a particular font, are defined in nonex- 
ecutable format To modify or add such functions, pre- 
programmed nonvolatile memory components are 
installed or data is transferred across an electrical sig- 
nal interface to be stored in volatile memory. Such trans- 
fer is conventionally called downloading. 
[0006] The address space of a conventional special 
purpose computing circuit is limited to one or a prede- 
termined few regions for nonvolatile memory and one or 
a predetermined few regions for volatile memory. When 
additional functions are Installed, the peripheral pro- 
gram scans the address space to identify installed and 
downloaded program code and data for incorporation 
Into the peripheral program and, consequently, into the 
functional aspects of the peripheral. 
[0007] Peripherals are said to "evolve** as a result of 
nmllfying or adding functions because tiie new or mod- 
ified functions are often, though not necessarily, related 
to one or more originally provided functions. Because 
computer systems are subject to frequent change, it is 
desirable to meet such change witii peripherals that are 
capable of evolving with less difficulty. Difficulties 
include tiie installation of physical memory components, 
tiie time consumed in downloading, and the limitations 
of address space in conventional systems. These diffi- 
culties signif icantiy increase costs associated with com- 
puter systems including the cost of ownership in a 
changing environment and the cost of maintaining a 
system tiiat meets changing specifications. 
[0008] In view of tiie problems described above and 
related problems, tiie need remains for systems and 
methods tiiat facilitate functional evolution for printers. 
[0009] Furtiier technical background Includes: "Devel- 
oping Client/Server Applications." by W. H. Inmon. QED 
Publishing Group of Wellesley MA, 1993; "RPC for NT," 
by Guy Eddon, R&D Publications of Lawrence KS. 
1994; and "Object-Oriented Languages, Systems and 
Applications." edited by Gordon Blair, et al., Halsted 
Press of New York NY. 1991 ; "Advanced Windows NT." 
by Jeffrey Richter, Microsoft Press of Redmond WA, 
1994; "Learn Java + + Now," by Stephen R. Davis, 
Microsoft Press of Redmond WA, 1996; and the biblio- 
graphic references contained tiierein. 

SUMMARY OF THE INVENTION 

[0010] Accordingly, a prerecorded data storage 
medium in one embodiment of the present invention 
includes a data storage medium and indicia recorded on 
the medium. The indicia Include instructions for per- 
forming on a provided computer a first metiiod for func- 
tional evolution of a provided printer, coupled to the 
computer. The printer has a printer function. The first 
metiiod includes (1) receiving at the printer a class def- 
inition which includes a second metiiod for image 
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processing; (2) forming an object instance In response 
to the class definition; and (3) binding the object so that 
the printer function is performed according to the sec- 
ond method, thereby accomplishing functional evolu- 
tion. 5 

[001 1 ] According to a first aspect of such an embodi- 
ment, the printer*s capabilities, i.e. the functional 
aspects of the printer function, are expanded when the 
printer function is performed according to the second 
method. 

[001 2] According to a second aspect, functional evo- 
lution is effected without introduction of software devel- 
opment techniques such as conventional compiling, 
linking, and loading, greatly simplifying expanded 
printer functions. 

[(K)1 3] According to another aspect, instantiation and 
binding are accomplished without direct reference to the 
address space of the printer. Therefore, limitations on 
address space are easier to avoid. 
[0014] According to yet another aspect, when instan- 
tiation and binding are accomplished by temporary allo- 
cation of memory that is later freed for other purposes, 
the evolution of separate functions can be accommo- 
dated at separate times without memory address limita- 
tions. 

[001 5] According to still another aspect, the class def- 
inition can be received at the printer by data communi- 
cation or by conventional installation of preprogrammed 
memory devices. Functional evolution, according to 
such an embodiment, can be accomplished with any 
combination of so-called "plug and play" and data com- 
munication. 

[0016] According to a further aspect, binding permits 
performance of the printer function according to the 
second method. When the printer function includes a 
call to the second method, the second method can over- 
ride a similarly named method of the printer function, or 
provide additional (supplemental) functional capability. 
When the second method includes a call to the printer 
function, the printer function can conditionally override a 
portion of the second method, or provide additional 
(supplemental) functional capability. In all of these 
cases, functions of legacy software such as the printer 
function evolve without recompiling the legacy software. 
[0017] Another embodiment of the present invention 
provides a method of printing on a printer The printer 
includes a first class definition having a function. The 
method includes: (1) exchanging a second class defini- 
tion between the printer and a computer; (2) instantiat- 
ing at the printer an object of the second class 
definition; (3) binding the object so that the function is 
performed when reference is made to the object; and 
(4) printing in response to the performance of the func- 
tion. 

[0018] According to a first aspect of such a method, 
the computer and printer cooperate after common rec- 
ognition of the secorKi dass definition regardless of 
whether the second class definition was prepared by 



the printer or the computer. When the second class def- 
inition prepared by the computer, additional methods 
such as video graphics rendering methods, can be 
added to the second class. When the second class def- 
inition is prepared by the printer, currently installed 
methods such as printed graphics rendering methods, 
can be added to the second class. What results is more 
accurate representation on a video display of images to 
be printed and more accurate representation on a 
printer of images displayed on a video monitor. Such 
consistency between a monitor and a printer provides a 
desirable improvement to the so-called what-you-see- 
is-what-you-get (WYSIWYG) systems capability 
[0019] According to another aspect, improvements in 
image processing for video systems and for printer sys- 
tems are shared. For example, an improved method of 
video rendering becomes available for printer rendering 
and vice versa. 

[0020] A computer system in yet another embodiment 
of the present invention includes a computer and a 
printer. The computer has stored indicia of a method for 
processing images to be displayed on a provided moni- 
tor. The computer forms a class definition in response to 
the indicia and transmits the class definition to the 
printer. The printer includes a class loader. The printer 
receives the dass definition, performs the method, and 
prints in response to the method. 
[0021 ] According to an aspect of such a computer sys- 
tem, a printer with a class loader can print using a 
method provided by the computer. Computation 
involved in the method is accomplished by the printer, 
reducing the computational burden at the computer. 
[0022] According to a second aspect, replacement of 
the printer with a second printer having an equivalent 
dass loader does not involve change at the conrputer. 
Computer system evolution is simplified. 

BRIEF DESCRIPTION OF THE DRAWING 

[0023] A preferred exemplary embodiment of the 
present invention is described below with reference to 
the drawing in which: 

Figure 1 is a block diagram of a computer system in 
one embodiment of the present invention; 
Figure 2 is a data flow diagram for a method of dis- 
playing and printing using a first portion of the com- 
puter system of Figure 1 ; 

Figure 3 is a data flow diagram for a method of dis- 
playing and printing using a second portion of the 
computer system of Figure 1 ; 
Figure 4 is a data flow diagram for a method of dis- 
playing and printing using a third portion of ttie 
computer system of Figure 1 ; 
Figure 5 is a memory map of the address space of 
a computing circuit in a printer in one embodiment 
of the present invention; and 
Rgure 6A, B. and C are class hierarchy diagrams 
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for a printer program in one embodiment of the 
present invention. 

DETAILED DESCRIPTION OF THE PREFERRED 
EMBODIMENT 

[0024] The present invention may be embodied in any 
system that includes an evolving printer. Such a system 
suitably indudes any group of components that interact 
to accomplish a conputational or measurement task. 
For example, computer system 100 of Figure 1 1ncludes 
subsystems at sites 102, 104. and 106. coupled by con- 
ventional network links 116. 122. and 140 to accomplish 
various conventional office automation tasks. Subsys- 
tem 102 includes personal computer (PC) 110, printer 

112, and net interface 114. Subsystem 104 Includes 
server 1 26. a local (or wide) area network 1 22. net inter- 
faces 130 and 132. one or more personal computers 
120, one or more printers 124, and one or more printers 
134. Subsystem 106 includes net interface 142 and 
printer 144. 

[0025] In computer system 100, printing is accom- 
plished with an evolving printer 112, 124, 134, and 144 
at each of several sites 102, 104. and 106. Printers 112. 
124, 134, and 144 represent any printing device using 
conventional technology including, for example, a laser 
printer, an ink jet printer, an impact printer, a photo- 
graphic printer. Each printing device suitably serves any 
application for an output device including, for example, a 
computer output printer, an instrumentation recorder, an 
office copier, a FAX machine, and a label or receipt 
printer. 

[0026] Personal computers 110 and 120 and server 
126 suitably include conventional keyboard and disk 
drive components (not shown) and a conventional mon- 
itor 108 and 118. In a conventional PC, scan lines are 
communicated across an electrical interface between 
the computer and monitor. In many computer systems, 
this interface does not include provisions for use as a 
network link. Therefore, the signaling frequency and 
data bandwidth are selected to tightly couple the com- 
puter and monitor, with the result that the monitor is 
dedicated to a single conriputer. 
[0027] In contrast, each printer 1 1 2, 124, 1 34, and 1 44 
is coupled to other components of system 100 by a link 

113, 123, 133, and 143. respectively. Each printer 
receives information governing printing and provides 
status of printer operations through the link. Links 113, 
1 23, 133, and 1 43 employ one or more physical connec- 
tions with corresponding network link functions to sup- 
port dedicated or shared services with various data 
communication protocols. Each printer 112, 124, 134, 
and 144 is capable of evolving functions, permitting the 
same printer to be attached to any link 1 13. 123, 133, or 
143 and operate without manual intervention. 

[0028] Unks 113. 123, 133, and 143, and net inter- 
faces 114. 130, 132, and 142 suitably include any con- 
ventional circuit for satisfying the physical and electrical 



demands of data communication for a particular chan- 
nel. Channels include any communication medium, for 
example, electrical and optical cable, audio signaling 
(telephony), radio frequency, and infrared. In a conven- 

5 tional net interface, one or more levels of protocol are 
accomplished, for example, collision detect multiple 
access, time domain multiplexing, and packet switching 
protocols. If desired, link and net interface support may 
be incorporated into the equipment to which each is 

10 connected. For example, printer 144 and net interface 
142 may be combined physically and electrically into 
one item. 

[0029] A computer system of the present invention fur- 
ther includes any distributed processing application pro- 

15 gram that facilitates functional evolution of an evolving 
printer. A distributed processing application program 
suitably includes any suite of computer program files 
and data files that cooperate to perform a function 
aaoss a link or net interface. For example, computer 

20 system 100 of Figure 1 includes suitable files that per- 
form methods of the present invention to be described 
below with reference to Figures 2, 3, and 4. These 
metiiods solve the profc>lems discussed above by facili- 
tating functional evolution for evolving peripherals. 

25 [0030] TTie particular configuration of a distributed 
processing application program may be the result of an 
ad hoc arrangement of components independentiy 
developed by various suppliers wherein each conpo- 
nent conforms to predetermined interfaces to pernrut 

30 cooperation as a distributed processing application pro- 
gram. Components of software systems 200. 300, and 
400 may be implemented in software (for example, 
machine code such as Intel Pentium Assembly lan- 
guage, or bytecode such as Java P-code), in firmware, 

35 by general purpose circuits, by state machine circuits, or 
any combination of these conventional techniques. 
[0031] The componertt processes and data items of 
software systems 200. 300, and 400 may be supplied by 
more tiian one vendor. For example, processes 202. 

40 206, and 220 may be supplied by an operating system 
vendor; process 204 and data items 214 and 244 may 
be supplied by a word processing application program 
vendor; processes 208, 210, and 212 may be provided 
by a monitor vendor; process 228 may be supplied by a 

45 network vendor; and processes 224, 226. and 240-256 
may be supplied by a printer vendor. The user conven- 
tionally relies on tiie cooperation of particular compo- 
nent processes selected ad hoc and witin reliance on 
predefined interfaces between these components. 

so [0032] A first distributed processing application pro- 
gram is any program that facilitates evolving functions 
for a PC linked with a printer. For example, software sys- 
tem 200 of Figure 2 facilitates evolving functions for PC 
110, link 113, and printer 112. Software system 200 

55 includes a suite of conponent processes and data 
items in PC 110 and printer 112. In PC 110, software 
system 200 includes graphical user interface (GUI) 202. 
user program 204, video pipe 205. operating system 



4 



7 EP0 926593 A2 8 



print pipe 225, PC print pipe 219, PC font data 214, and 
PC communication process 229. In printer 112, soft- 
ware system 200 further includes printer communica- 
tion process 241 , printer font data 244, printer print pipe 
243, and access process 253. 
[0033] Software system 200 may include any conven- 
tional user interface, for example. GUI 202. A user inter- 
face accepts direction from a user and provides a 
command that invokes display or printing of data. GUI 
202 is of the type provided by an operating system, 
such as a Windows operating system marketed by 
Microsoft of Redmond, WA. 

[0034] Software system 200 may include any conven- 
tional user program 204, for example a word processor 
or computer aided design program. Such a user pro- 
gram accepts the command to display or print data from 
memory or from a file on disk. User program 204 identi- 
fies, by conventional techniques, the subject matter to 
be printed. For the purpose of illustration in the discus- 
sion below, the subject includes text in scalable fonts 
and overlapping graphics images. Other, more or less 
complex, subject matter may be identified for display or 
printing. 

[0035] A video pipe includes one or more processes 
that reformat data identified for display into scan lines 
for presentation on a raster display device, such as 
monitor 108. For exanrple. video pipe 205 includes 
video driver 206. render process 208, and rasterize 
process 210. A video driver prepares a data in an inter- 
mediate format from the subject. For example, video 
driver 206 prepares intermediate data by conventional 
techniques, in bit-map format from sul^ect data in vec- 
tor, symbol, outline, position and control, or bit-map for- 
mats. Driver 206 includes methods for creating 
commonly used bit-map images such as lines, geomet- 
ric shapes, and text characters from conventional algo- 
rithmic and parametric definitions. 
[0036] A rendering process integrates (paints) inter- 
mediate data on an image data structure. For example, 
render process 208 prepares a bit-map image data 
structure by conventional techniques from intermediate 
data desalbing portions of an image requiring further 
processing. Such processing may include compensa- 
tion for matters of screen composition including overlap- 
ping images, images that extend beyond the allowed 
display area, edge or color enhancement, scale, orien- 
tation, shadowing, or animation. Bits in the image data 
structure correspond generally to pixels to be displayed. 
[0037] A rasterizing process provides data in scan 
lines from an image data structure. For example, raster- 
ize process 210 provides binary pixel intensity values 
sequentially, by conventional techniques, for each hori- 
zontal scan line of each color plane used by monitor 
108. Rasterize process 210 may account for matters of 
screen size, persistence, or brightness. Raster process 
210 may include methods for converting some or all of 
the received image data structure into vectors for dis- 
play on a compatible monitor in place of monitor 108. If 



desired, processes 208 and 210 may be combined by 
conventional techniques to reduce the amount of mem- 
ory needed to retain image data structures. 
[0038] A display process receives output from a video 

5 pipe and operates any conventional display device 
including, for example, storage tube, cathode ray tube, 
liquid crystal, or field emission display. For example, dis- 
play process 212 in monitor 108 receives scan lines 
from video pipe 205 for conventional graphics raster dis- 

10 play. Display process 21 2 maintains the image on mon- 
itor 108 until replaced in whole or in part by a new 
image. 

[0039] For printable subjects, it is desirable to accom- 
plish a printed result that closely resembles the image 
75 as it would be displayed on a monitor. According to the 
present invention, processes used in preparing to print 
are permitted to use the processes discussed above for 
preparing to display. 

[0040] A print pipe includes one or more processes 
20 that reformat data identified for printing into a format for 
communication across a link to a printer, such as printer 
1 12. For example, operating system (OpSys) print pipe 
225. includes OpSys formatter 221 and OpSys Queue 
223 that provide data in bit-map image format to port 
2S monitor 224. OpSys formatter 221 and OpSys queue 
223 are of the type that are integral to an operating sys- 
tem for supplying defeult printing capability, for example, 
a print pipe of the Windows 32-bit operating system 
marketed by Microsoft. Such a print pipe may be set to 
30 render all items, as in the case of support for Java 
Developer's Kit (JDK) 1 . 1 .x. 

[9041 ] A print pipe that supports evolving printer func- 
tions performs a minimum of reformatting operations 
prior to supplying data to be communicated over a link 

35 to a printer. For example. PC print pipe 219 includes 
print driver 220 and queue 222 that provide data in one 
of several formats to print monitor 224. In addition, print 
driver 220 responds to defaults or user input to direct 
printing of the identified subject data through either 

40 OpSys print pipe 225 or to process the identified subject 
data without leaving prirrt pipe 219 for supporting evolv- 
ing printer functions. 

[0042] When data is directed to OpSys print pipe 225. 
the subject data is rendered by OpSys formatter proc- 

45 ess 221 to provide a bit-map data structure as 
described atxsve for video driver process 206 and 
render process 208. OpSys formatter 221 may include 
methods for aeating commonly used bit-map images 
such as lines, geometric shapes, and text characters 

50 from conventional algorithmic and parametric defini- 
tions. The resulting bit-map data structure is provided to 
port monitor 224 for communication across link 113. 
[0043] On the other hand, when the subject data pro- 
ceeds tiirough print pipe 219. print driver 220 takes 

55 advantage of the capabilities of and accommodates the 
limitations of printer 112. For example, for image items 
tiiat can be rendered by printer 112, print driver 220 
reformats the subject data to provide to port monitor 
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224 either identification or definition information in any 
fbrnnat compatible with intervening communications 
processes and printer 1 12. For image items that printer 
112 cannot render, print driver 220 reformats tiie sub- 
ject data into intermediate format as described above. 5 
Print driver 220 may include methods for aeating com- 
monly used bit-map images such as lines, geometric 
shapes, and text characters from conventional algorrtii- 
mic and parametric definitions. The resulting bit-map 
data structure is provided to port monitor 224 for com- 10 
munication across link 113. 

[0044] By foregoing conversion to a bit-map interme- 
diate format and foregoing a rendering process, print 
driver 220 delivers more compact data to port monitor 
224 for efficient communication. Consequentiy, PC 1 10 75 
Is relieved from the processing burden of rendering data 
to be printed, memory in PC 110 is better utilized, and 
printer 1 12 is permitted to efficiently render and raster- 
ize according to methods specifically configured for 
printer 112. 20 
[0045] Font data bases 21 4 and 244 include any con- 
ventional font data structures. Video driver 206 and print 
driver 220 obtain information for specifying text charac- 
ters from font data base 214. Information in font data 
base 214 is extensible from, and shared with, font data 2S 
base 244 in printer 1 12 as indicated by the ellipsis on 
both 214 and 244 in Figure 2. 
[0046] A print queue stores data for sequentially 
requested print jobs. A print queue buffers data in a 
generally first in first out protocol and may provide man- 30 
agement functions for the contents of tiie queue. For 
example, OpSys queue 223 includes storage space for 
targe intermediate data structures and provides com- 
plex monitoring, cancellation, and priority control to 
manage data flow. Data remains in OpSys queue 223 35 
from a time when rendering of a first of several related 
subject data items begins until communication of the 
last related subject data item is successful. This period 
of time is made long by tiie complexity of rendering and 
the duration of communicating large intermediate data 40 
structures. 

[0047] In contrast, queue 222 incliKles storage space 
generally used for image items (such as a geometric 
shape, a scalable font character, an overlaid graphic 
witii shading, etc.) to be identified or defined rather tiian 45 
rendered within the PC 1 10. An item is identified by any 
reference, for example a character number reference 
within the context of an identified fixed size font. An item 
is defined by any data structure setting fortii parameters 
for an algorithmic rendering, for example a shaded rec- so 
tangle or a scalable character of particular point size, 
weight, and color. In a preferred embodiment, queue 
222 is omitted because port monitor process 224 can 
keep pace with tiie output of print driver process 220. 
[0048] A communication process is any program tiiat 55 
assists tiie transfer of data across a link. For example, 
communication process 229 assists the transfer of data 
in Intermediate format, image bit-map format, dass def- 



initions, broker messages, oommunications status mes- 
sages, and communication control messages across 
link 113. Communication process 229 in PC 110 
includes port monitor 224, page description language 
(PDL) process 226, comnxinication stub 228, and bro- 
ker stub 252. Communication process 241 in printer 1 1 2 
includes communication stub process 240, PDL proc- 
ess 242. and broker stub 254. 
[0049] A port monitor communicates status, com- 
mands, and data to a printer. For example, port monitor 
224 communicates with pnnter 112 by sending and 
receiving messages tiirough PDL process 226 and 
maintenance processes not shown. A maintenance 
process reports status of the printer including condition 
of media supplies, current configuration details, paper 
jams, etc. Maintenance messaging is accomplished, for 
example, using the conventional Simple Network Man- 
agement Protocol (SNMP). Port monitor 224 receives 
data from OpSys print pipe 225 and from PC print pipe 
219, assembles messages from tiiese data according to 
a conventional message protocol and passes each 
message to the PDL process. 
[0050] A page description language (PDL) is a proto- 
col for data ti'ansfer with a printer. A PDL provides botii 
graphics and text communication capability and 
includes identification and definition of fonts 244. Con- 
ventional PDLs include the Printer Control Language 
(PCL) language marketed by Hewlett Packard Co. of 
Palo Alto. CA, Postscript language marketed by Adobe 
of San Jose, CA. and IPDS marketed by International 
Business Machines of Boca Ratan, FL. A pair of PDL 
processes communicate according to any PDL. For 
example, PDL processes 226 and 242 cooperate to 
assemble and disassemble messages according to the 
PCL language. PDL processes 226 and 242 provide tiie 
in-bound and out-bound functions that convert data 
structures to and from port monitor 224 into and out of 
messages tiiat comply with a PDL 
[0051 ] A communication stub is any process that pro- 
vides the lowest level protocol functions that support 
pactet data communication. For example, communica- 
tions stub processes 228 and 240 employ conventional 
techniques to communicate data across a conventional 
electrical interface, for example, link 113 between PC 
110 and printer 112. Communications stub processes 
support conventional data communication by provkiing 
physical and electrical signaling protocols that support 
message passing functions including signal discrimina- 
tion, packet checking, retransmission procedures, and 
acknowledgment procedures. 
[0052] A print pipe in a printer receives data describ- 
ing what is to be printed and operates a print engine 
(not shown) for producing marked media in response. 
Conventional print pipes include techniques for improv- 
ing the quality of the printed image such as edge 
enhancement, dot shifting for h\Q\n& apparent resolu- 
tion, accommodation of the expected and measured 
physical aspects of the print engine such as mechanical 
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positions, current temperatures, current voltages, and 
accommodation of expected and measured aspects of 
the media. For example, print pipe 243 includes render 
process 246. rasterize process 248, and print process 
250. 

[0053] Render process 246 and rasterize process 248 
perform rendering and rasterizing functions respectively 
within the context of laser printing in a manner similar to 
processes 208 and 210 discussed above in the context 
of displaying. Render process 246 produces a Isit-map 
image data structure for rendering a page at a time or, if 
desired, for rendering a band at a time. Raster process 
248 converts the image data structure to scan lines for 
printing by process 250. If desired, processes 246 and 
248 may be combined by conventional techniques to 
reduce the amount of memory needed to retain image 
data structures. 

[0054] A print process receives data from a communi- 
cation process and operates any conventional media 
marking mechanism including electrophotographic 
printing, laser printing, scanned or vector driven optical 
imaging onto film, and Inkjet printing. For example, print 
process 250 operates a laser printing mechanism by 
receiving scan lines from communications process 241 
and directing laser printing operations for producing 
paper bearing the desired image. For full color printing, 
scan lines may be grouped by primary color in the con- 
ventional manner or provided simultaneously for high 
speed color printing. 

[0055] An access process is any process tiiat exposes 
functions across a link. For example, access process 
253 exposes classes of functions in printer 1 12 for the 
purpose of facilitating evolving printer functions. Access 
process 253 includes print peer 256 and native proxy 
258. 

[0056] PDL process 242, render process 246. and 
rasterize process 248 are examples of processes that 
include evolving functions as indicated by the ellipsis 
shown in Figure 2, These processes each include exe- 
cutable program code located within the program 
address space of the printer's computing circuit, inter- 
pretable program code or data structures located within 
the data address space of the printer's computing cir- 
cuit, or a combination of both executable and interpreta- 
ble code. A function, implemented in executable or 
interpretable code, evolves according to the present 
invention when it is modified by replacing, extending, 
supplementing, or conditionally modifying its opera- 
tions. Such modification is facilitated, for example, by an 
object oriented run-time environment having dynamic 
binding of objects. 

[0057] Functional evolution may be better understood 
in light of the following brief overview of object-oriented 
programming concepts, including classes, objects, 
interfaces, and dynamic binding. Concepts and termi- 
nology used to describe software systems 200, 300. 
and 400 are intended to be consistent witii current 
research, industry standards, and tine conventions of 



the current major manufacturers and developers of 
computer systems and software. 
[0058] A class is any template used to define one or 
more objects. A class is defined in source code using 
the syntax of an object oriented programming language, 
such as Java. C + +, Smalltalk, or Eiffel. A class speci- 
fies at least three types of components: variables, meth- 
ods that operate on the variables, and interfaces. 
Classes are conventionally defined in a hierarchy, as 
shown for example, in Figure 6 A. The hierarchy pro- 
vides for method sharing and functional evolution. 
[0059] An object is any instance of a class from which 
it was defined. Objects come into existence by instanti- 
ation during run-time. Instantiation of a child object 
involves allocation and initialization of data memory for 
the storage of variables and pointers fbr the chiki object 
as well as storage of variafc)les and pointers defined by 
all parent objects above the child in the class hierarchy 
[0060] The object oriented programming language in 
cooperation witii class loading and dynamic linking sup- 
ports HfKXIif ication of a class hierarchy during run-time. 
For example, a base class may be used to define a 
derived class wherein tiie derived class includes (a) 
additional metiiods for objects tiiat were already defined 
in the base class (overloading), new substitute methods 
to be used in place of metiiods defined in tiie base class 
(overriding), (c) new objects that utilize (inherit) meth- 
ods already defined, (d) alternate hierarchical relation- 
ships among already defined objects so that method 
inheritance during dynamic linking is modified, or (e) 
any combination of these techniques. A modified class 
provides functional evolution when an object of tiie 
modified class is instantiated and dynamically bound. 
[0061] A class defines methods by defining for each 
method a specification and possibly an implementation. 
The specification includes a signature and provisions 
for exceptional conditions which may arise when tiie 
method is performed (such as overflow, etc.). The sig- 
nature includes a name for the method, the names and 
types of its arguments, and the type of its return value (if 
any). The implementation of a method Onterpretable or 
executable code) has one or more entry points, i.e. 
memory addresses or offsets that identify where per- 
formance (execution or interpretation) will commence. 
When tiie specification is not accompanied by an imple- 
mentation, tiie method is called a virtual function. 
Objects defined in classes that derive from an interface 
cooperate at run-time via pointers collectively called a 
virtual function table. In some run-time environments, a 
virtual function table is one of the data structures that is 
allocated when an object is instantiated. A virtual func- 
tion table includes pointer variables fbr entry point val- 
ues determined at run-time, pointer constants when 
offsets to entry points can be predicted at compile-time, 
or a combination of variables and constants. 
[0062] Any association of a particular method with an 
object is called binding. Binding, when accomplished at 
least in part at run-time is called dynamk: binding. When 
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a method of a particular object is dynamically bound, an 
entry point value is assigned to an appropriate pointer 
variable in a virtual function table of the particular 
object. Thereafter, an indirect reference tiirough the vir- 
tual function table initiates performance of the method. 
The determination of which entry point Is appropriate for 
the method is accomplished by comparing the signature 
(or simply the name) of the method with signatures (or 
names) of all methods in the dass hierarchy (beginning 
witii tiie particular object) until the first match is found. 
By choosing the first match regardless of the possibility 
of other matches which may exist in the class hierarchy, 
the behavior of the particular object exhibits polynrwr- 
phism by overriding, overloading, or sharing by inherit- 
ance tiie behavior of other objects. 
[0063] An object oriented run-time environment sup- 
ports run-time polymorphism, for example, by direct 
execution or by interpretation. For example, software 
systems 200, 300, and 400 include an object oriented 
run-time environment including executable program 
files developed in the C and C + + programming lan- 
guages and a real time operating system. Further, print 
peer 256 includes a class loader and a conventional 
Java Virtual Machine (JVM). The class loader recog- 
nizes class definitions developed in the conventional 
Java programming language and prepares them for 
interpretation by tiie JVM. The JVM performs printer 
peer functions by instantiating objects described by 
classes (lo^ed by the class loader) and performing 
methods of the Instantiated objects. Before a method of 
an object can be performed the metiiod must be associ- 
ated with an entry point. The process of such associa- 
tion includes conventional dynamic binding either at tiie 
time an object is instantiated or immediately before a 
particular method of tiie object is to be performed. 
[0064] Access process 253 cooperates with broker 
stub processes 252 and 254 to expose printer functions 
of printer 11 2 for use by PC 11 0 and to expose functions 
of PC 110 for use by printer 112. PDL process 242 
includes classes of objects with implementations in 
interpretable program code (bytecode). Render process 
246 and rasterize process 248 include legacy subrou- 
tines in executable program code developed without the 
benefit of an object oriented programming language. 
Native proxy 258 identifies tiie entry points in processes 
246 and 248 to provide a legacy class interface, similar 
in format to the class interfaces provided by the specifi- 
cations in classes of PDL process 242. Consequentiy. 
printer peer process 256 is able to make uniform refer- 
ence to classes of PDL process 242, as well as classes 
of legacy processes 246 and 248. 
[00S5] A broker stub is any process that provides 
object resource brokering. For example, broker stub 
processes 252 and 254 include any conventional object 
resource brokering facility, for example, brokering facili- 
ties developed from or compliant with techniques of 
remote procedure call (RPC). remote method invocation 
(RMI) as marketed by JavaSoft. Inc., tiie CORBA stand- 



ard as defined by Object Management Group (an indus- 
try consortium), or the distributed common object model 
(DCOM) marketed by Microsoft, Inc. Such a brokering 
facility includes broker message transfers for (a) identi- 

5 fication of classes in another member of a network, (b) 
transfer of a class definition (data structure) between 
members of a network, and (c) notification of excep- 
tional conditions (network node unavailable, dass not 
found, etc.). In addition, brokering involves allocating 

10 memory for receiving a class definition, cooperating 
with a dass loader for integrating the class definition 
into tiie receiver's dass hierarchy, and cooperating with 
a virtual machine for instantiation of objects of the dass 
definition, dynamic binding of metiiods and perform- 

75 ance of methods according to the class definition. When 
knowledge of a method signature has been communi- 
cated to anotiier member of a network, tiie method is 
said to be exposed. The receiving member is then ena- 
bled to utilize tiie method for its independent purposes 

20 by performing the copy of the implementation received 
during tiie course of object resource brokering. Public 
metiiods of any process in PC 1 10 are exposed by bro- 
ker stub process 252 so that, for example, a method of 
render process 208, rasterize process 210, PDL proc- 

25 ess 226, or any other useful method is made available 
to printer 1 12. 

[0066] A second distributed processing application 
program is any program that fadlitates evolving func- 
tions for printers tiiat are supported by a print server. 

30 For example, software system 300 of Figure 3 facilitates 
evolving functions for printers 124 and 134 as sup- 
ported by server 126. Software system 300 is similar to 
software system 200 wherein processes of software 
system 300 are functionally and structurally identical to 

35 similarly named counterparts numbered less 100 in 
software system 200, except as described below. 
[0067] Software system 300 includes a suite of com- 
ponent processes and data items in PC 120 and print- 
ers 124 and 134. In PC 120. software system 300 

40 includes graphical user interface (GUI) 302, user pro- 
gram 304, vkfeo pipe 305. PC print driver 372. PC font 
data 314. and PC communication process 373. In 
server 126, software system 300 includes communica- 
tion stub process 378, operating system print pipe 325, 

45 server print pipe 31 7, and communication process 331 . 
In printer 124 (and similarly in printer 134. not sepa- 
rately shown), software system 300 further indudes 
printer communication process 341, printer font data 
344, printer print pipe 343, and access process 353. 

50 [0068] Functions of print driver 220 in software system 
200 are divided between PC print driver 372 and server 
print driver 382 in any convenient manner. For example, 
PC print driver 372 provides data in a common format to 
be communicated to server print driver 382. Server print 

55 driver 382, executing on server 126, performs those 
functions unique to printer 124 or 134 and other opera- 
tions so as to lessen the computational burden on PC 
120. PC print driver 372 cooperates witii communica- 



8 



15 



EP0 926 593 A2 



16 



i 



tion stub 378 to route data in common format to either 
OpSys print pipe 321 or to print pipe 31 7. 
[0069] Communication stub processes in software 
system 300 provide any suitable protocol support for 
network and dedicated links. For example, process 376 s 
and 378 support link 121, shown in Figure 1, processes 
383 and 340 support link 123 for printer 124 and link 
133 for printer 134, not shown. Link 133 may be either a 
network link (for uniformity) or a dedicated link (for secu- 
rity, speed, or maintenance purposes). Link protocols 
include, for example, ethernet. Transmission Control 
Protocol/Internet Protocol (TCP/IP). Hypertext Transfer 
Protocol (HTTP), and SNMP as discussed above. In a 
variation of links 123 and 133, additional (alternate or 
layered) link protocols are implemented using conven- 
tional techniques. 

[0070] Broker stub processes in software system 300 
provide object resource brokering of the type described 
for software system 200. For example, resource broker- 
ing in software system 300 exposes functions of printers 
124 and 134 to server 126 and to PC 120 and exposes 
PC functions to server 126 and printers 124 and 134. 
[0071 ] In software system 300, server print driver 382 
also exhibits functional evolution in a manner similar to 
the functional evolution described with reference to soft- 
ware system 200. For example, classes from PC print 
driver 372 may be transferred to server 126 to provide 
or modify server print driver 382. 
[0072] A third distributed processing application pro- 
gram is any program that facilitates evolving functions 
for printers that initiate or maintain a link without user 
interaction. For example, software system 400 of Figure 
4 facilitates evolving functions for printer 144 as sup- 
ported by server 126. Software system 400 is similar to 
software systems 200 and 300 wherein processes of 
software system 400 are functionally and structurally 
identical to similarly named counterparts numbered 
less 200 in software system 200, and less 100 in soft- 
ware system 300 except as described below. 
[0073] Software system 400 includes a suite of com- 
ponent processes and data items in server 126 and 
printer 144. In server 126, software system 400 includes 
site manager 485, page bank 484, page pipe 419, and 
communication process 429. In printer 144, software 
system 400 includes communication process 445, 
printer print pipe 417. print pipe 487, and access proc- 
ess 453. 

[0074] A site manager any process identified by a net- 
work address for providing data across a link. For exam- 
ple, site manager 485 is a conventional site manager, 
identified by a uniform resource locator (URL) that 
receives requests using HTTP and responds by trans- 
mitting a "page** as a message or file, compliant with the 
Hypertext Markup Language (HTML). Data is requested 
by conventional techniques including specification of a 
full address, a partial address, a set of search criteria, or 
as a result of a link from a previously identified page. 
Data transfers are accomplished by conventional tech- 



niques, for example, TCP/IP. In addition, site manager 
process 485 includes any conventional network man- 
agement capability, for example the capability to oper- 
ate as a file server, a database system, or a member of 
the internet or of the world wide web. 
[0075] A page pipe provides data to a queue in a man- 
ner analogous to a simple print pipe, such as print pipe 
317. For example, page pipe 489 includes page driver 
486 which provides data to queue 422. A page driver 
provides any format-independent page-queuing capa- 
bility. For example, page driver process 486 provides an 
HTML file generator and queue manager. When page 
bank 484 includes one or more pages already in HTML 
format, page driver merely queues the requested 
page(s). Othenwise, a message in HTML Is formulated 
from data from page k>ank 484, or system information, 
such as information provided by site manager program 
485, broker stub 474, or the server operating system, 
not shown. 

[0076] Communications process 429 is an analogous 
simplification of communications process 229 dis- 
cussed with reference to Figure 2. Process 429 includes 
port monitor 424, communication stub 428 and broker 
stub process 474. A page description language process 
is omitted from communication process 429 because 
page driver 486 provides data in HTML format and si^- 
port for TCP/IP is provided by communication stub 428. 
Broker stub process 474 is similar in structure and func- 
tion to broker stub 252 discussed with reference to Rg- 
ure 2. Broker stub process 474 provides access to 
exposed methods (if any) of site manager 485, page 
driver 486, or server operating system, not shown. 
[0077] Communication process 429 cooperates with 
communication process 445 to support link 140. Com- 
munication process 445 includes communication stub 
process 440, site poll 488, and broker stub 454. A site 
poll process is any browser or file transfer agent capa> 
ble of initiating requests for data across a link. For 
example, site poll process 488 Includes any conven- 
tional network browser or file transfer agent and. if 
desired, includes a browser of the type marketed by 
Microsoft or by Netscape together with a shell or script 
that invokes a request for a predetermined page (or 
search criteria) at a predetermined time of day, without 
manual intervention by a user. 
[0078] Communication stub processes 428 and 440. 
and broker stub processes 474 and 454 include conven- 
tional data communication and object resource broker- 
ing capabilities, as described above, for exposing 
printer 144 functions to server 126 and for exposing 
server 126 functions to printer 144. 
[0079] Components of a distributed processing appli- 
cation program occupy memory of a PC, server, or 
printer, as discussed above and generally illustrated by 
a memory map. For example, memory map 500 of Fig- 
ure 5, generally corresponds to a portton of memory of 
any one printer 112, 124, 134, or 144 in one embodi- 
ment of the present invention. Map 500 includes appro- 
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priate components of software systems 200, 300. or 
400. The address space of nonvolatile memory 510 
includes firmware operative when power is applied. 
Space 520 includes any printer operating system kernel 
having an object oriented run-time system. If desired, 5 
the system kernel Includes the communications stub 
240. 340. 440 firmware, an embedded operating system 
of the type marketed as VxWorks by Wind River Sys- 
tems, Inc., a dass loader, and a Java virtual machine 
(JVM). The JVM includes a conventional processor 10 
(firmware and/or hardware) of the type providing just-in- 
tlme compilation. Printer processes such as print proc- 
esses 250, 350, and 450 occupy space 522 (print 
engine control). Render and rasterize processes 246, 
248. 346, 348, 446, and 448 occupy space 524 (format- 75 
ter). 

[0080] A memory manager process occupies space 
526. A memory manager includes any conventional 
firmware for identifying downloaded items such as per- 
sonalities 562 and fonts 564 and for performing gaibage 20 
collection (deallocation of nonreferenced memory) in 
spaces 562 through 570. 

[0081] Spaces 528, 530, and 532 are rested for 
built-in (i.e. native) functions. PDL process 242 or 342 
(personality) is built-in. Fonts 244, 344, and 444 are 2S 
built-in. And, classes implementing portions of the ker- 
nel, class loader, Java virtual machine, native proxy 
(258. 358. 458), printer peer (256, 356. 456), and broker 
stub (254. 354. 454) are built-in. 

[0082] Address spaces 534. 536, 538, and 540 are 30 
reserved for the installation of memory devices pro- 
grammed for nonvolatile expansion capabilities includ- 
ing additional personalities (PDL capabilities), fonts, 
and Java classes, such as classes for site poll and print 
driver processes 488 and 420 in printer 144. 3S 
[0083] The address space of volatile memory 51 2. for 
the embodiment discussed above, includes areas to be 
initialized after power is applied. Space 552 is reserved 
for common variables and stacks used primarily by ker- 
nel firmware. Page definition buffers 558 include work- 40 
ing memory for intermediate format Items provided by 
PDL process 242, 342, or queue 422. Page buffers 554 
include working memory for pixel arrays identified as 
image data provided by render process 246, 346, or 
446. Raster buffers 552 include working memory for a 45 
page or band of scan lines provided by rasterize proc- 
ess 248. 348, or 448. Communication buffers in space 
560 support memory allocated by communication stub 
240. 340, or 440 and broker stub 254, 354, or 454. 
[0084] Spaces 562, 564. and 566 illustrate tiie possi- so 
bility of downloading any combination of personalities 
(PDL support processes), fonts, and Java classes via a 
conventional page description language data transport 
mechanism or via the broker stub mechanism described 
above. When a particular loaded item is not currently ss 
referenced, gart>age collection will permit the memory 
used by that item to be reused. Fragmented memory 
address spaces are coalesced by tiie gart^age collec- 



tion process to permit larger contiguous address 
spaces to be available for downloaded items and instan- 
tiated objects. 

[0085] Space 568 illustrates memory for instantiated 
ot3jects Including space for variables, virtual function 
tables, and other data staructures. Pointer values in vir- 
tual function tables in volatile memory area 568 are set 
by dynamic binding to entry point (e.g. physical 
address) values of metiiod implementations stored in 
nonvolatile memory (e.g. in spaces 524, 528. 532, 534, 
and 538) and/or volatile memory (e.g. in spaces 562, 
566. and 568). 

[0086] An evolving printer responds to modified class 
definitions. For example, evolving printer 112, 124, 134, 
or 144, in one embodiment, responds to a modified 
dass definition as shown in tiie hierarchy diagrams of 
Figures 6 A. B, and C. A modified class definition is pre- 
pared and used for printing according to a method of tiie 
present invention illustrated as follows witii reference to 
Figure 2: 

1. Upon recognition of the need to inquire into cur- 
rentiy available printer functions (built-in or as 
installed), print driver 220 passes a request by 
dass name tiirough brokers 252 and 254 for the 
signature of all metiiods in dass: 

Object. Ck>rTponent.Container.Graphics. Print 

Peer 

2. Print peer 256, aware of the possibility that video 
methods could be useful, passes a request by dass 
name through brokers 254 and 252 for the signa- 
ture of all methods in class: 

Object Component.Container.Graphic.Video 

class 

3. Broker 252 responds with class definition 600 
tiiat includes public methods Rotate, Draw_Triangle 
(equilateral), and Draw_Star (6-point star) exposed 
from render process 208; 

4. Print peer 256 creates a modified class definition 
620 tiiat indudes a copy of the implementations of 
the public metiiods received in dass definition 600. 
These implementations are assumed to relay on 
atomic methods such as Draw_Line that would be 
inherited appropriately from tiie PrintPeer object or 
from tiie Video object. The dass loader places the 
dass in address space 566 of volatile memory, see 
Figure 5; 

5. Print peer 256 creates a modified class definition 
640 that indudes a proxy for each shared method of 
dass 600 (Each proxy generates the appropriate 
PDL command to invoke the underlying PrintPeer 
method); 

6. Broker 254 returns modified class definition 640 
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to broker 252, enabling user program 204 to effi- 
ciently print a star image Item; 

7. On receipt of a PDL command directing the gen- 
eration of a star image item, render process 246 s 
makes reference to PrintPeer. Draw.Star of class 
definition 620: 

8. A PrintPeer object of the class 620 is instanti- 
ated; 10 

9. Dynamic binding of the instantiated object directs 
program flow for the Draw_Star method to the 
Draw_Triangle and Rotate methods p.e. pointers 
are assigned addresses in region 566); is 

10. Dynamic binding of the instantiated object 
directs program flow for the atomic Draw_Line 
method (needed for Draw-Triangle) to the built-in 
Draw_Line method (I.e. pointers are assigned 20 
addresses in region 524); and 

11. Render process 246 generates the star image 
using the Java virtual machine Irrterpretation of the 
received Draw_Star implementation and the native 2S 
legacy code of region 524. The code in region 524 
implements Draw_Line in a manner that accounts 

for physical attributes of the print engine including 
accommodation for neighbor pixels, for example 
edge enhancement technologies. 30 



[0087] Printing a WYSIWYG image according to 
another method of the present invention includes the 
steps of: 

35 

1 . Invalidating the contents of a displayed (or dis- 
playable) frame (a container class object); 

2. Directing output of a screen repaint object to the 
print pipe supporting evolving printer functions, for 40 
example by creating an alternate reprint derived 
object under class: Object.Component.Con- 
tainer.Graphics.PrintPeer (thus Inheriting an atomic 
level print output method) ; and 

45 

3. Activating the alternate reprint object thereby 
printing the image. 

[0088] The foregoing description discusses preferred 
embodiments of the present invention, which may be so 
changed or modified without departing from the scope 
of the present invention. For example, program code 
that includes instructions to perform a printer function 
may be stored in any conventional mOTory device 
including an EEPROM. EPROM, ROM. CDROM, or 55 
magnetic hard disk, flexible disk, or tape. Such media 
includes indicia of instructions in any format including 
compressed and secure formats. A printer function 



includes any process relied upon to produce printed 
output, for example print peer process 256, 356, or 456, 
communications processes, rendering and rasterizing 
(formatting) processes, and etc., as described herein, 
and conventional functions as known in the art. 
[0089] These and other variations and modifications 
are intended to be included within the scope of the 
present invention. While for the sake of clarity and ease 
of description, several specific embodiments of the 
invention have been described; the scope of the inven- 
tion is intended to be measured by the claims as set 
forth below. The description is not intended to be 
exhaustive or to limit the invention to the form disclosed. 
Other variations of the invention will be apparent in tight 
of the disclosure and practice of the invention to one or 
ordinary skill in the art to which the invention applies. 

Claims 

1. A prerecorded data storage medium having 
recorded Indicia comprising instructions for per- 
forming on a provided computer (110, 126) a first 
method for functional evolution of a provided printer 
(112. 124, 134, 144) coupled to the computer, the 
printer having a printer function, the first method 
comprising: 

receiving at the printer a class definition (600) 

comprising a second method (610); 

forming an object instance (620) in response to 

the class definition; and 

binding the object so that the printer function is 

performed according to the second method. 

thereby accomplishing functional evolution. 

2. The medium of Claim 1 wherein the method further 
comprises requesting the class definition. 

3. The medium of Claim 1 wherein the printer further 
comprises a first class definition having a first class 
name and the step of requesting comprises the first 
dass name. 

4. The medium of Claim 1 wherein the first class defi- 
nition comprises a first method implementing the 
printer function, and the binding overrides the first 
method. 

5. The medium of Claim 4 wherein the request con- 
forms to a protocol of the group consisting of SNMP, 
hypertext transfer protocol, page description lan- 
guage, remote procedure call, remote method invo- 
cation, and CORBA. 

6. TTie medium of Claim 1 wherein the class definition 
is received in a protocol of the group consisting of 
SNMP. hypertext markup language, page descrip- 
tion language, renrrate procedure call, remote 
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method invocation, and CORBA. 

7. The medium of Claim 5 wherein printer function 
comprises instructions for receiving data at the 
printer. s 

8. The medium of Claim 1 wherein receiving com- 
prises a method compliant with a page description 
language. 

10 

9. The medium of Claim 1 wherein receiving com- 
prises a method compliant with a network manage- 
ment protocol. 

10. A prerecorded data storage medium having 75 
recorded indicia comprising Instructions for per- 
forming a method for providing access to a printer 
function, the method comprising transmitting a 
class definition from the printer, the class definition 
comprising an identification of the printer function. 20 
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